1. Field of the Invention
The present invention generally relates to data processing and more particularly to 3270 applications migrated for use on TN3270 network architecture.
2. Description of the Related Art
Data processing systems, methods and computer program products that use a 3270 data stream architecture have been widely used for decades. Systems using the 3270 data stream architecture are often referred to as “legacy” systems. Details regarding the 3270 data stream architecture are described in “IBM 3270 Information Display System Data Stream Programmer's Reference”, published by International Business Machines Corporation (IBM), the assignee of the present application, IBM Publication Number GA23-0059-07, 1982, the disclosure of which is hereby incorporated herein by reference.
In general, the 3270 data stream controls the processing and formatting of data with commands, orders, control characters, attributes, and structured fields. The 3270 data stream operations are used primarily for transmitting data between a host application and a client. More specifically, the 3270 data stream architecture is used to communicate between a Primary Logical Unit (PLU) and a Secondary Logical Unit (SLU) using the LU2 protocol. The PLU typically performs functions associated with the host application. It will be understood that the primary and secondary logical units may be mainframe computers, midrange computers, personal computers, terminals, workstations or one or more computer programs that execute on one or more of such computers.
The above described environment may be further understood with reference to FIG. 1. As shown in FIG. 1, a data processing system (100) includes a PLU (110) and an SLU (120) that communicate with each other over a network (130) using the 3270 data stream. The PLU (110) may also be referred to as a host, and the SLU (120) may be referred to as a terminal, workstation, emulator or client. The SLU (120) typically includes a keyboard and a display device. The PLU (110) includes a host application (140), which communicates with the SLU (120) via the network (130). The SLU (120) includes a presentation space (PS) (180). The PS (180) is the collection of information that together comprises the information to be displayed on a screen of a terminal in the SLU, as well as the control data that conveys how and where that information is to represented. It will be understood that, although FIG. 1 illustrates a simple data processing system (100) including one PLU (110), one SLU (120) and a simple network connection (130), the 3270 data stream architecture is generally used to communicate among many PLUs and SLUs using complex network environments.
PLUs and SLUs communicate in a Systems Network Architecture (SNA). The SNA is the logical structure, formats, protocols, and operational sequences for transmitting information units through, and controlling the configuration and operation of, networks. Thus, in the context of FIG. 1, where the network (130) is a SNA network, the host application (140) is a 3270 application.
The 3270 data stream is an arrangement of bytes and can be an outbound data stream or an inbound data stream. The outbound data stream is a data stream sent from the host application (140) to the SLU (120) and includes data, a command, and if a write type command, a write control character (WCC). An inbound data stream is sent from the SLU to the host application and consists of an attention identifier (AID), followed by data. The AID is a byte that describes the action that caused the transmission of the inbound data stream. The data is the information transferred between the host application and the SLU.
The command from the host application (140) is sent to the SLU (120) to initiate the total or partial writing, reading, or erasing of portions of the PS (140). Commands are sent as a command code in the first byte of a request/response unit (RU) chain. Examples of typical command codes may be found in TABLE 1 below.
TABLE 1CommandEBCDICLocal Channel non-SNAWriteX′F1′X′01′Erase/WriteX′F5′X′05′Erase/Write AlternateX′7E′X′0D′Read BufferX′F2′X′02′Read ModifiedX′F6′X′06′Read Modified AllX′6E′N/AErase All UnprotectedX′6F′X′0F′Write Structured FieldX′F3′X′11′Referring to TABLE 1, EBCDIC (Extended Binary-Coded Decimal Interchange Code) is a coded character set consisting of 8-bit coded characters. EBCDIC is the standard decimal interchange code for IBM mainframes. Local Channel non-SNA refers to a network that attaches emulators, terminals, and workstations, which may communicate with other locally attached devices without using the SNA network.
The WCC is the byte following a write command used to specify that a particular operation, or combination of operations, is to be performed at a terminal or printer. For the write command, the WCC is bit encoded with bits 0-1 set depending on the values in bits 2-7. TABLE 2 below, indicates the functions of the WCC bits.
TABLE 2BitFunction0-1Depends on values in bits 2-72-3For printers4Start-printer bit5Sound-alarm bit6Keyboard restore bit7Reset MDT bits in the field attributesWhen bit 6 of the WCC is set to 1, the command unlocks the keyboard, and resets the AID byte.
Recently, many users have abandoned 3270 terminals in favor of personal computers (PCs). However, because most host applications on the mainframe were written to run on 3270 terminals in a SNA network, a terminal emulator that permits PCs to access an IBM mainframe was necessitated. Generally, the terminal emulator causes the PC to appear as a 3270 terminal to the mainframe. One method of doing this is with a Telnet 3270 terminal emulator (TN3270). Additional information regarding TN3270 can be found in RFC 2355.
An exemplary illustration of the relationship between a SNA network and a TN3270 network is found in FIG. 2. In FIG. 2, the data processing system (100), includes the PLU (110), including a host application (140), which communicates with the SLU (120) via the SNA network (130). In contrast to FIG. 1, the SLU (120), shown in FIG. 2, is split between two entities, a TN3270 server (150) and a TN3270 client (170), which communicate via a TN3270 network (160). The TN3270 client (170) has a PS (180) which is used to display information on a display device.
The TN3270 performs the function of modifying the display information sent by the host application (140) on the mainframe, and formatting it for display on the PC. In other words, the TN3270 manipulates the presentation space (180). In a typical attempt to modify the PS (180) on the TN3270 client (170), the host application (140) communicates the 3270 data stream via the SNA network (130), using SNA network protocols. The TN3270 server (150) receives the 3270 data stream and translates the SNA network protocols into TN3270 network protocols, leaving the payload the same, thus, creating a TN3270 data stream. As part of this processing, the TN3270 causes 3270 data streams to be encapsulated in telnet TCP/IP packets. The TN3270 server (150) then sends the TN3270 data stream to the TN3270 client (170) via the TN3270 network (160). The TN3270 client (170) receives the TN3270 data stream and updates the PS (180) with the payload.
After the host application (140) completes its modification of the PS (180), the PLU (110) sends either an end bracket (EB) or a change direction (CD) to the SLU (120) to indicate that the PLU is done updating the PS (180). The EB is sent from the PLU (110) to the TN3270 server (150), and indicates that the PLU (110) is done updating the PS (180), and that either the SLU (120) or PLU (110) may begin a communication. In particular, the EB places the session in a contention state. The contention state is when both the PLU and SLU are able to initiate a communication. In the contention state, if both the PLU and SLU simultaneously begin a conversation, the SLU will prevail. When in the contention state, the host application may send a BID or a SIGNAL to the SLU. The BID is a request to begin a communication. The SLU may accept or reject the BID. One reason for rejecting the BID is if the PS has been modified by an entity on the SLU-side, such as a user. In the case of a modification of the PS by the user, the SLU must reject the host application's BID attempt so that the SLU can report the modifications to the host application. In a typical TN3270 environment, the TN3270 server rejects all BIDs from the host application.
The SIGNAL is an SNA command that is a demand from the host application to the SLU, or vice versa, to begin a communication. If the SLU receives a SIGNAL it must allow the host application to communicate. Upon receipt of a SIGNAL, the SLU may send all changes to the PS to the host application, as well as a change direction (CD). The CD may be sent by either the PLU or SLU, and indicates that only the PLU may begin a communication, and that the SLU will not interrupt any communications.
In a pure SNA network (as shown in FIG. 1), the EB would implicitly unlock the keyboard. However, when SNA applications are migrated for use on the TN3270 network (as shown in FIG. 2), there is no implicit unlocking of the keyboard. In general practice, a well-mannered TN3270 server does not pass the EB to the TN3270 client; rather, the server generates and communicates an X′F1C2′ command. An X′F1C2′ command is a write command with WCC having keyboard restore bit on (i.e., bit 6). Thus, the X′F1C2′ command unlocks the keyboard. The current practice of a TN3270 server is to generate and communicate to the TN3270 client an X′F1C2′ upon receipt of an EB from the PLU. However, because X′F1C2′ can be generated by both the TN3270 server and the host application, the TN3270 client is not explicitly aware of the EB and will not know that the host application is done updating the PS. The same is true when the TN3270 receives a CD, except that a CD does not include an implicit keyboard store.
Therefore, there is a need for determining whether the PS is completely built in a TN3270 environment.